The past years have witnessed a tremendous increase in the traffic volumes in both WANs like the Internet and also on-premise LANs like the Ethernet. This increase in traffic volume is due to new technologies, migration from a paradigm of central to distributed computing and a host of new applications. Also, the fast pace of technology growth is witnessing increasingly inter-disciplinary work in which groups of individuals from diverse groups/divisions come together for a project and disband. From a networking standpoint, this implies that the typical communities of interest (COI) such as a department no longer are the rule and in fact these COI are regularly changing. This results in severe network management problems. In addition to traffic volumes and network management problems there is also a bewildering variety of co-existing applications such as telephony, video and data networking. The seamless integration of these services poses an extreme challenge in both the premises network and the wide-area network. This has resulted in a dramatic shift from the present method of operation which typically involves routers and bridges to switching in the premises.
A type of switch architecture that has been considered is a dual-bus-based one with bus slots supporting various port cards that interface to the external world. FIG. 1 illustrates the switching hub architecture 10 including a switch fabric which is a dual-bus architecture where all port boards 25a, 25b, . . . , 25n transmit on a transmit bus 30 and receive from a separate receive bus 40. The transmit bus 30 is looped back onto the receive bus 40 through a loop-back circuit 45 located at the far end of the bus. In the example configuration of FIG. 1, the busses run at multi-Gbps speed, supporting port cards with aggregate rates up to OC-12. The port cards 25a, 25b, . . . , 25n are likely to have various interfaces ranging from CBR circuits like T1.5, Ethernet segments, ATM connections to desktops etc. In particular, such an architecture (or like) is considered as an attractive solution for access and backbone in campus, private or corporate networks.
Access to the bus is achieved via a variation of a round-robin discipline with priorities. Transmission on the bus is in units of envelopes which are ATM cells, e.g., wrapped in some local switch fabric headers which includes sequence numbers, flags and addressing information among other. It is assumed bus collision avoidance is accomplished by a suitable bus arbitration mechanism. The switching architecture could be employed to switch variable-sized as well as fixed size packets. On each visit of the poll to a port card, it is assumed that only one envelope is served. This is sufficient to maintain high throughput in a short backplane because the propagation delay is small and envelope transmission and arbitration by polling can be completely pipelined.
Referring back to FIG. 1, each port card 25a, 25b, . . . , 25n interfaces to the bus via a high-speed chip indicated as respective BIC (Bus Interface Chip) chips 50a, 50b, . . . , 50n that are assumed to have simple high-speed FIFO staging buffers 60a, 60b, . . . , 60n, respectively, for transmission on the unidirectional bus 30 and receipt from the unidirectional bus 40. The port cards 25a, 25b, . . . , 25n each contain a large amount of slow-speed memory, e.g., indicated as RAM 75a, 75b, . . . , 75n to serve as the primary buffering area to and from the actual physical ports represented as input and output arrows 31 to and from each respective RAM. Thus, the function of the BIC memory space 60a, 60b, . . . , 60n is to serve as a staging area for envelopes generated on the transmit side and as a rate-converter (from the bus transmission rates to the port transmission rates) on the receive side. Due to the large potential difference in rates between the bus speed and port rates, buffer overflows are a serious issue on the receive side of the BIC.
Routing in the fabric is achieved based on a logical addressing scheme whereby an address is assigned to each "logical" egress point which represents either a port card, in which case it will be referred to as a physical address as well, a port or even an ATM connection (VP/NVCI). Note that no source addressing is used in the switch, and hence all addresses refer to an egress point. As mentioned above, this logical (physical) address is part of the local envelope header. On the receive side, BICs use this address to filter envelopes destined to them.
There are many simple techniques for implementing physical flow control schemes for unicast-type traffic, e.g., by sending out a control packet or envelope containing buffer congestion indication to the sending BIC board and, for deactivating such flow control for unicast streams by sending a flow control packet that signals deactivation for streams destined to a particular physical address. However, multicast traffic, i.e., where ATM cell traffic is sent from a single source to multiple port boards, has its unique flow control problems. In multicast, routing is accomplished by simply assigning the same logical address to multiple physical entities (ports or boards).
Since the receiving BICs are potentially distinct in their traffic patterns and congest and un-congest independently, flow control is complicated. There are several known flow control strategies, ranging from simple strategies to sophisticated strategies. Simple strategies includes transmitting at a source to conform to the slowest receiver, i.e., the sender flow controls whenever any receiver is congested. Sophisticated strategies include flow control by the sender only when a significant number of receivers are congested. Strategies of the latter type are aimed at feeding the uncongested receivers at the fastest rate possible and not penalizing them for congestion at the slower receivers. However, they suffer from the disadvantage that a reliable multicast service will now require retransmissions to the slower receivers at a later time to overcome the losses. Sophisticated schemes are too complicated to implement at the BIC level and hence a simplistic flow control strategy is desired to operate multicast control at the sender when any receiving BIC is congested and de-controlling only when all the BICs are uncongested.
It would thus be highly desirable to provide a simple flow control mechanism by which congestion status of BICs receiving multicast streams may be determined and which may be appropriately used to de-control the sender.